<html>
<body>
Reports assignments of application services to static final fields / immutable properties.
<h4>Static final fields (Java) or static immutable properties with backing fields (Kotlin)</h4>
<p>
  <b>Note:</b> Hereinafter, static in Kotlin refers to members of non-anonymous objects or top-level declarations.
</p>
<p>
  Such services' assignments contribute to global state and make it impossible to tear down an application and set up another one in tests,
  therefore, repeated tests in the same process may fail.
  The only exception is an explicit constructor call to store dummy/default instances.
</p>
<p>
  The recommended way to avoid storing services is to retrieve a service locally.
  Alternatively, one can wrap it in <code>java.util.function.Supplier</code> (Java, Kotlin)
  or convert the property to a function (Kotlin).
</p>
<p>Example (Java):</p>
<pre><code lang="java">
// Bad:
private static final ManagingFS ourInstance = ApplicationManager.getApplication().getService(ManagingFS.class);
</code></pre>
<pre><code lang="java">
// Good:
private static final Supplier&lt;ManagingFS&gt; ourInstance = CachedSingletonsRegistry.lazy(() -> {
  return ApplicationManager.getApplication().getService(ManagingFS.class);
});
</code></pre>
<pre><code lang="java">
// Exception:
private static final UniqueVFilePathBuilder DUMMY_BUILDER = new UniqueVFilePathBuilder()
</code></pre>
<h4>Retrieving a service instance through static immutable properties (Kotlin)</h4>
<p>
  While services' assignments to properties without backing fields don't cause the aforementioned problem,
  using an explicit <code>getInstance()</code> method to retrieve a service is preferred over using a property:
</p>
<ul>
  <li>It makes it clearer on the call site that it can involve loading the service, which might not be cheap.</li>
  <li>Loading the service can throw an exception, and having an exception thrown by a method call is less surprising
    than if it was caused by property access.</li>
  <li>(Over-)using properties may be error-prone in a way that it might be accidentally changed to a property with an initializer
    instead of the correct (but more verbose) property with a getter, and that change can easily be overlooked.</li>
  <li>Using the method instead of a property keeps <code>MyApplicationService.getInstance()</code> calls consistent
    when used both in Kotlin, and Java.</li>
  <li>Using the method keeps <code>MyApplicationService.getInstance()</code> consistent with <code>MyProjectService.getInstance(project)</code>,
    both on the declaration and call sites.</li>
</ul>
<p>For better tooling performance, it is always advised to keep an explicit method return type.</p>
<p>Example:</p>
<pre><code lang="kotlin">
@Service
class MyApplicationService {
  companion object {
    @JvmStatic
    val instance: MyApplicationService // bad
       get() = service()
  }
}
</code></pre>
<pre><code lang="kotlin">
@Service
class MyApplicationService {
  companion object {
    @JvmStatic
    fun getInstance(): MyApplicationService = service() // good
  }
}
</code></pre>

<!-- tooltip end -->
<p><small>New in 2023.3</small>
</body>
</html>